『Scaling Teams 開発チーム 組織と人の成長戦略』読んでみた

はじめに

CX事業本部グローバルチームの藤村です。この度マイナビ出版から 『Scaling Teams 開発チーム 組織と人の成長戦略』 が発売されたので、早速購入して読んでみました。

なぜ読んだのか

この本の紹介文を引用します。

本書は、IT企業の幹部、とくに、ソフトウェア・エンジニアリング、製品管理、デザイン、品質保証などの担当幹部を対象にしています。 規模で言えば、スタートアップや、一定以上の規模の組織で新たに結成された10人から250人のチームが主たる対象です。

そのなかでも、規模が急拡大中のチーム、俗に言う「ハイパーグロース」を遂げつつあるチームのニーズに焦点を当てています。

以下がクラスメソッド社の従業員数推移となります。

※FY2020は2020年6月5日現在の見込み

参考: 財務ハイライト

私が入社したのはFY2019期初(FY2018期末)で、当時の社員数は150人強。今現在300人オーバーということで、まだ入社してから2年も経ってないのに既に後輩の数が先輩の数を越えてる！

また、以下が私が所属するCX事業本部の従業員数推移となります。

このように、会社も部署も「ハイパーグロース」まではいかないにしても、急激に従業員数が増加している状況で、色々と考えなければならないことも増えてきていると感じていたため、この本を手に取りました。

読みながらのつぶやき

私は本を読むとき、いわゆるソーシャルリーディングと呼ばれるような手法で読書することが多いです。自分が気になった点を引用して自分のコメントともに紹介すると、コメントに対して多くの方々(たまに、本の著者や訳者の方も！)からフィードバックを得ることができ、学びを深めることができるので、とってもオススメの読書法です。

今回も『Scaling Teams 開発チーム 組織と人の成長戦略』を読みながらSNS上でつぶやいた内容をいくつかピックアップし、改めてふりかえってみました。

「規模拡大(スケーリング)」がらみの問題が起こるたびに慌てて極端な舵切りをするのではなく、すでに成功を遂げた他社の実証済みの解決策を採り入れ、それを自社独自の状況から生じた特有の問題に応用するほうが良いのだ。そうした「実証済みの解決策」を集めた道具箱(ツールボックス)が、まさしく本書であり、きっと皆さんのお役に立てると考えている。

ツールボックス的な本大好き。ワクワクしてる。

"はじめに"の最初の段落からの引用となります。道具箱(ツールボックス)的、またはプラクティス集的な本が大好きな私は、序盤からめっちゃテンションアゲアゲな気持ちになりました。

なぜプラクティス本が好きかというと、それは私がプラクティス厨だからであり、なぜ私がプラクティス厨なのかについては以下のスライドを参照ください。

また、私が愛してやまないプラクティス本は、こちらになります！

• アジャイルサムライ
• アジャイルな見積りと計画づくり
• リーン開発の現場
• Running Lean
• エッセンシャルスクラム
• これだけ！　ＫＰＴ

「開発チームの規模が20人を超えた場合、1年未満で規模を倍増しようとすると問題が生じる可能性がある」

めっちゃ思い当たる節がある…。

私自身、過去に10回以上転職してきたこともあり、この状況は会社としても部署としても開発チームとしてもそれぞれ体験してきていました。直近で開発チームをスケールさせようとして痛い目にあったお話しは、以下のスライドにまとめてます。

たとえば離職率が10%だから問題なしと思っていたが、ふと気づくと、辞めていくのは成績優秀な社員ばかりだった、というのでは明らかに健全ではない。辞めた社員全員について調べ、「残念な離職」なのか「残念ではない離職」なのかを見極める必要がある。

優秀な社員の転職先が大手外資系企業なら仕方ないみたいな意見も聞くけど、自分はそうは思わない。そこで思考停止したくない。

これについては、色々思うところがあります！めっちゃ優秀な同僚が、その実力を認められて世界的に有名な外資系企業から声がかかるなんてすげー！おめでとう！って思う一方で、やっぱりそれも「残念な離職」に分類されると思います。過去に10回以上転職してきた私がいうのもなんですが、そんな誘いをもらっても余裕で断っちゃうぐらいに良い会社、良い環境にしていきたいと、強く思っています。

私自身、クラスメソッドにJOINしてもうすぐ2年になりますが、いつもならムクムクと転職欲が出てくる頃なのに、まったく出てきません。昔からの知人は、「日和った」とか「守りに入ってる」とか散々言いますが、私自身そんな理由で在籍しているのではなく、クラスメソッドが最高の会社だから留まっているんです！現状に満足することなく、さらに魅力的な会社にしていきたいなって思ってます。

とくに急成長中の企業では、人事管理に明示的に照準を定めることこそが全社レベルの成功のカギとなる。しかるべき研修を受けた管理者が健全な文化のもとで、チームの士気を鼓舞し、会社の目標に沿った作業の割り振りを図り、対立を解決し、成長の次なる段階へ向けて技術チームの体制を固めることによって、チームのスケーリングを助長できるのだ。

これが重要だと思って、この本読んでる。

引用した文章の中で、特にしかるべき研修を受けた管理者という点が重要だと考えてます。マネージメントは、片手間で自己流にできるようなものではありません。15年ほど前になりますが、私が初めてマネージャーを任された際は、まさに片手間で自己流にマネージメントを行なってしまったことで、チームにもかなり迷惑をかけていたかと思います。その時同僚のマネージャーからマネージメントスキルの欠如を指摘された際は、そのフィードバックを真摯に受け止めること無く、うるさいなーぐらいにしか思ってませんでしたが、今振り返ってみると彼が言いたかったことがとても理解できます。

技術部門の管理者の会合などで訊いてみてほしい ー 「皆さんの中で、エンジニアとして研鑽を積んだ方は何人ぐらいいらっしゃるでしょうか」。一貫して80%から100%の人の手が上がるはずだ。これに対して「管理者になる前に、管理に関する正式な研修を受けた方は？」と尋ねると、なんと0%から10%という正反対の驚くべき結果が出ると思う。なぜかIT業界では技術部門の管理の職務を、ほぼ完全に「現場で仕事を通じて習得するもの」と捉えているのである。

マネジメントの専門的なトレーニング、継続的な研修は絶対必要だと考えている。ただ、胡散臭い研修が多いのも事実。どう見極めると良いんだろう。

上で書いた、しかるべき研修を受けた管理者と同じ課題になります。なぜ管理者は自己流で習得できるものと考えられちゃうんでしょう…。IT業界でエンジニアに、「どのようにしてエンジニアリングについて学んでいますか？」って聞いた際、「感と経験と度胸を頼りに自己流でノリで開発してます！トレーニングを受けたどころか、本を読んで勉強したこともありません！これからも学ぶつもりありません！動いてるんだから良いでしょ？」って言われたらどう思いますか？そんなエンジニアは第一線の企業ではとても働くことは難しいでしょう。マネジメントとなると、なぜそれが許容されてしまうのでしょうか。この状況は変えていかなければならない強く考えています。なんて偉そうなことを言う前にまずは自分が専門的なトレーニングを受けなければ…。

そもそも自律性を100%有するチームだけから成る会社に、どんな存在意義があるのか。こんな状況では「規模の経済(生産量が増えるにつれて単位当たりの平均費用が減り、利益率が上がること)」など見込めない

これはめっちゃ同意。チームの独立性を突き詰めると、同じ組織に属する意義がなくなる。規模の経済を考えてバランスを取っていきたい。

組織の縦割り、横串の話です。部署が拡大し、部署内のチーム数も増えていくと、どうしても縦割りな組織構造になりがちです。もちろんチームの自律性も重要ですが、各チームが独立性を再重視して横の連携を軽視したら、大変非効率な組織になってしまうと考えています。管理しやすいからという理由でそれぞれのチームの部分最適化に走るのではなく、もう一つ上の視点で全体最適化を考え、組織として大きな目標に向かっていけるような環境にしていきたいと考えています。そうしていかなければ、同じ組織に属している意義を見い出せません。

デリバリーチーム編成の4通りのアプローチ
・プラットフォームに焦点を当てるアプローチ
・機能に焦点を当てるアプローチ
・事業に焦点を当てるアプローチ
・顧客グループに焦点を当てるアプローチ

今まで、プラットフォーム(コンポーネント)か機能(フィーチャー)の視点しか持ててなかったけど、事業や顧客グループ視点でのアプローチもあったか。試してみたい。

アジャイルの文脈でもよく話題に上がるフィーチャーチームか、コンポーネントチームかについて、組織の状況や各種制約が異なると目指すべき組織の形も変わってくるのでどちらが正解ってのは無いと思ってますが、今まで基本的にはチーム内で機能の実現を完結できるフィーチャーチームを目指してました。そのように今までは2択で考えてしまっていたのですが、今回この書籍を読んで、事業や顧客グループ視点でのアプローチもあることを学び、視野が広がりました。

4通りの報告体制
・ひとりのエンジニアリングマネージャーがひとつのデリバリーチームを管理するアプローチ
・ひとりの管理者がひとつのデリバリーチーム全体を管理するアプローチ
・ひとりの管理者がひとつの専門領域に対する責任を追うアプローチ
・人事専門の管理者がひとりですべてのエンジニアを束ねるアプローチ

続いてレポートラインの話。うちの現場は、2番目と3番目の組み合わせかな。参考になる。

2019年7月にCX事業本部が誕生して以降、チーム編成やレポートラインについて試行錯誤しながら組織設計を進めてきています。その辺りの経緯は、以下の記事を参照ください。

• クラスメソッドに10年勤務してるワイが、社長のTweetを見ながら色々と振り返ってみる

• さようならDevOps支援室、こんにちはCX事業本部

もちろん、この書籍の中に正解が書いてあるわけではありませんが、議論するメンバーの知識レベルを合わせる意味でも最低限この書籍の内容を全員が理解した上で議論できると良いなと考えています。

ステップ1 ー コアバリューの「発見」
・このメンバーで会社を始めたのはなぜだろう？何が決定的な要因だったんだろう？
・私達(俺達)が一番重要だと思うことは何だろう？どんな製品がいいと思う？どんなふうに行動するのがいいと思う？
・私達(俺達)が「ベストの状態」って、どんなとき？
・新入社員を雇うときに、「これは外せない」って思うことは何？
・「5年後になっても、これだけは変えたくないね」って思うもの、何かある？

この辺りは、クラスメソッドのカルチャーとしてうまくまとめられてると思ってる。

クラスメソッドのカルチャー(CLP: Classmethod Leadership Principle)は、以下のページにまとめられています。

クラスメソッドのカルチャー Classmethod Leadership Principle

私のお気に入りのCLPベスト3は、以下となります！

ダイバーシティ

年齢・性別・国籍・人種・宗教・性的指向・障害の有無など、多様な価値観があることを学びます。また、出産・育児・介護などのライフステージに寄り添い、互いに助け合い、これを強みとします。

私自身、この1年間はベトナムの開発パートナーとの連携強化に力を入れてきており、ベトナムエンジニアのアサイン数も、ベトナムエンジニアとの協働プロジェクト数も右肩上がりに増えてきています。

また、我々が多国籍のチームを作っていくのは、単に人的リソースのスケールだけを求めているわけではありません。

グローバルチーム立ち上げ当初に作ったインセプションデッキはこちらになります。最終的なゴールはクライアントのビジネスの成功とし、それに向けて人的リソースのスケール(＝クライアントの期待に応えるチームを直近で作るため)、今後を見据えた多国籍チーム開発のノウハウ蓄積(＝クライアントの期待に応えるチームを今後も作っていくため)、働き方自体の多様性の担保（＝海外からのリモートワーク）、クラスメソッドのエンジニアスキルの底上げ(＝世界のエンジニアとの切磋琢磨)なども視野にいれています。

この辺りの取組については、以下のスライドにまとめています。

今後も引き続きベトナムエンジニアとの連携強化に注力し、多様性のあるプロジェクトチームが当たり前であり、日本人メンバーしかいないプロジェクトが珍しいような組織を作っていきたいと考えています。

顧客視点

お客様を起点に深く考え、相手が本当に必要なものは何か、心地良い体験は何か、それらを発展及び継続的に提供するためにはどうしたら良いか考えて物づくりをします。

私自身、元々はサーバサイドエンジニアでしたが、エンジニアリングは物づくりする上での手段の一つに過ぎないと考えており、技術の押し売りになってしまってはいけないと考えています。お客様が本当に必要なものを提供する上で、高い技術力は必要条件ですが、十分条件ではなく、常に顧客ファーストの視点を大切にしたいと考えています。

楽しむ

とても難易度の高い仕事、人の嫌がる仕事、大きな環境の変化を好み、成長の機会として楽しみます。これらを楽しめるように心身共に健康な状態を保ちます。皆が楽しく仕事ができるように、発言し行動します。

人生の大半の時間を費やす仕事は、楽しいものでなければならないと考えています。私自身、アジャイルな開発プロセスやアジャイルの考え方が大好きなので、そんな大好きなアジャイルの導入推進の仕事が楽しくて仕方ありません。また、東南アジア、特にベトナムという国やベトナムの人々との交流も大好きなのですが、仕事でベトナムメンバーとコミュニケーションができる、仕事としてベトナムに頻繁に行けるなんて、喜びでしかありません。

一点重要なのは、自分自身が楽しめる仕事は待っていても向こうから勝手にやってくるなんてことはほぼなく、自ら勝ち取っていかなければならないということです。アジャイル好き好きアピールしていたら、大橋さんに声かけてもらってクラスメソッドに入社し、DevOps支援室の立ち上げを任せてもらえました。ベトナムの魅力を積極的にアピールしていたら、グローバルチームの立ち上げを任せてもらえました。パリス・ヒルトン好き好き言ってたら、パリス・ヒルトンに会ってインタビューすることができました(10年以上前ですが…)。自分が好きなこと、仕事として楽しめることを言い続け、行動し続け、それを仕事にすることが、充実した人生を歩むコツかなと考えています。

面接時の質問：「面接のプロセス、製品、ビジネス手法などで弊社が改善すべき点は何だと思いますか」
有能な候補者なら、遠慮せずに、しかしキツイ表現をうまく避けながら、改善点やアイデアをあげてくれるはず

この質問良いな。早速参考にしたい。"キツイ表現をうまく避けながら"ってのがポイントだな。キツイ表現で指摘する人は、入社後に問題になるケースが多い。

私自身、礼節を大変重視しており、どんなに能力が高くても礼節を欠く方とは一緒に働けないと考えています。礼節については同僚のkwappaさんのスライドが大変参考になります。

この本読んだ後、早速面接でこの質問をしてみたところ、まさにキツイ表現をうまく避けながら改善点を答えてくれた方がいて、コミュニケーション能力や課題解決能力の一端を垣間見ることができました。この質問はオススメです。

会社が拡大するにつれて他の部門やチームの作業内容が把握しづらくなってくることがある。そんな時、2、3週に1度の割合で各チームの短いプレゼンテーションを見られれば、大いに助かる。

今はチーム内だけで実施してるスプリントレビューのデモのダイジェスト版を各チームのPdMが持ち寄って開催するの良さそう。

上でも書いたとおり、チームの独立性が進んだ結果、他のチームがやっていること、得意なこと、困ってることなどが見えにくいという課題を感じています。CX事業本部の中でもScrumを採用しているプロジェクトは多数あり、各プロジェクト毎に毎週のスプリントレビューでインクリメントのデモを実施しているので、このデモの内容を各チームで持ち寄れば、特に新たな手間を増やすこと無くチームの横の連携を強められるのではないかと思いました。このチーム横断デモデイは、CX事業本部のPdMチームの定例MTGの枠組み内ででまずはやってみたいと考えています。

我々自身は「すべてのステータスミーティングが例外なく無用というわけではないが、次の3点のどれかに該当するものなら廃止を検討するべき」と考えている。
・終了後に有意義なフォローアップメールが作成できない(どの出席者の頭にも、話し合うべきトピックが浮かんでこない)ようなステータスミーティング
・出席者が多すぎて15分では終わらないステータスミーティング
・現況報告に価値を見出だせる人物がひとりしかいない(多くの場合、管理者のみとなってしまった)ステータスミーティング

これらが該当するデイリースクラム多そう。良い指標。

多くのプロジェクトにおいて、朝会、夕会、デイリースクラムなどの日次によるミーティングが行われているかと思います。その中で、この時間を有意義に使ってチームのコラボレーションやパフォーマンスを最適化しているチームもあれば、形骸化して惰性で継続しているチームもあるかもしれません。ここに書かれている観点で観察し、ミーティングがちゃんと機能しているかどうかの指標として、今後使っていきたいと思いました。

"「実際に肩を並べて2、3日共同作業するだけで、遠隔通信での作業を何ヶ月続けても得られない親近感が生まれてくる」"

"実際に顔を合わせてのミーティングは一切なし、会議は一律、遠隔通信で、という方針"

"祝賀会など、企業やチームの文化に関わる行事には遠隔地のチームメンバーも参加してもらう努力を払うべきだ。こちらへ出向いてもらうのでも、同じ行事を向こうのオフィスで催すのでもよい。"

マルチサイトのコミュニケーションに関する施策は万国共通だし、特に目新しいアイデアも無いな。VRがソリューションになる時代はいつ来るんだろう。

我々はグローバルチームということで、今までマルチサイトのコミュニケーションに関する施策は色々と試行錯誤してきていました。その結果重要だと考えている点は以下となります。

我々が試行錯誤してきたのは新型コロナウイルスのパンデミック前のため、基本は直接顔を合わせることを重視してきましたが、今後しばらくの間はそれが難しくなるかと考えています。だからといって何かを諦めるのではなく、新技術や新しいアイデアを使った新しい試みを試すチャンスだとポジティブに考え、発想を転換していきたいと考えています。

まとめ

本書は道具箱(ツールボックス)というだけあって、今日から使える実践的なプラクティス満載の本でした。また、本書の最終章である12章にはそれまでに紹介されてきた「必須のプラクティス」、「問題の兆候」とそれに対しての「推奨される対策」が表でまとめられており、定期的に「問題の兆候」が現れてきていないかチェックするだけでもかなり有益な内容になっていると思いました。

私自身、この書籍の中での一貫したメッセージは、組織変更は丁寧にやれ！ってことだと理解したので、手間を惜しんだり、効率よく進めようなどは考えず、丁寧に丁寧に進めていきたいと考えています。

ソフトウェア開発を行なう組織の、組織づくりを考える方にとって、自信を持ってオススメできる本ですので、興味持った方はぜひ読んでみてください。そして、内容についてSNS上で議論しましょう！

さいごに

今までソーシャルリーディングするときは、SNS上にコメントを書きっぱなしで読書を終えてしまっていたのですが、今回改めて自分自身のコメントを見返してみたところ、より書籍の内容の理解を深めることができました。今後もSNSでのソーシャルリーディング＆ブログによるふりかえりという組み合わせで読書していきたいと思います。